home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 7031 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.1 KB  |  71 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: comp.vuw.ac.nz!HERMES!maths!peterm
  3. From: peterm@maths.grace.cri.nz (Peter McGavin)
  4. Subject: Re: AddIntServer + VERTB strangeness
  5. Message-ID: <PETERM.96Apr8105533@tui.maths.irl.cri.nz>
  6. Date: 07 Apr 1996 22:55:33 GMT
  7. References: <199604021335.NAA17260@mailhost.unibol.com>
  8.     <PETERM.96Apr7121414@tui.maths.irl.cri.nz>
  9. Organization: Industrial Research Ltd
  10. In-reply-to: peterm@maths.grace.cri.nz's message of 07 Apr 1996 00:14:14 GMT
  11.  
  12. I wrote:
  13. >High-level OS calls should internally use the same hardware allocation
  14. >mechanisms as our own program, so there should be no conflicts.  For
  15. >example, a high-level graphics.library function might call
  16. >OwnBlitter() and WaitBlit() before it bangs the blitter, just as we
  17. >could in our own program.
  18.  
  19. Sorry, I posted in too much haste.  John Girvin is right that there is
  20. a risk of deadlock.  For example, our program could directly or
  21. indirectly call a high-level blitter function, e.g, RectFill() or a
  22. floppy track decoding function, while we own the blitter between
  23. OwnBlitter() and DisownBlitter().
  24.  
  25. However, provided simple rules are followed, deadlocks can happen only
  26. with hardware allocation functions that block.  Fortunately, apart
  27. from OwnBlitter(), all hardware/resource allocation functions I can
  28. think of do not block.  They immediately return a succeed/fail status
  29. instead.  So only OwnBlitter() is at risk as far as I know.
  30.  
  31. Anyway, to minimize the risk of deadlock to practically nil:
  32.  
  33.   o  Avoid calling OS functions that might use the blitter while the
  34.      blitter is owned.  Do not own the blitter for long.  Perhaps use
  35.      QBlit() instead (which does not block).
  36.  
  37.   o  When a hardware allocation function fails, put up a Retry/Cancel
  38.      requester or equivalent.  If the user retries, simply attempt the
  39.      allocation again.  If the user cancels, free everything allocated
  40.      so far and either exit the program or wait until the user does
  41.      something to try again.
  42.  
  43. There is also a risk with LoadView(NULL) for allocating custom gfx.
  44. That's because LoadView() is not a true allocation function.  The risk
  45. is that another program could call LoadView() while we are banging the
  46. custom chips.  Steps that can be taken to minimise this risk include:
  47.  
  48.   o  Install an input-handler before calling LoadView(NULL) and
  49.      remove it after restoring the original View.  That prevents
  50.      the user attempting to flip Screens with left-Amiga-M.
  51.  
  52.   o  Turn off (most?) system requesters for our process:
  53.        pr = (struct process *)FindTask(NULL);
  54.        oldWindowPtr = pr->pr_WindowPtr;
  55.        pr->pr_WindowPtr = (APTR)-1; /* suppress requesters */
  56.        ...
  57.        pr->pr_WindowPtr = oldWindowPtr;
  58.      See pages 567..568 of The Amiga Guru Book for more details.
  59.  
  60.   o  SetFunction() LoadView() to be a no-op function that saves
  61.      its argument in our variable, saved_actiview say.  At the
  62.      end, restore the LoadView() function (leaving a stub behind,
  63.      unfortunately) and call LoadView(saved_actiview).
  64.  
  65.   o  Inform the user that this program takes over custom gfx and
  66.      warn against simultaneously running other programs that do
  67.      the same.
  68. -- 
  69. Peter McGavin.   (p.mcgavin@irl.cri.nz)
  70.  
  71.